前言

昨天的文章介紹到了 HTTP/1.1 所定義的請求方法中的安全/不安全方法，今天就來介紹一下請求方法的另外一種分類-Idempotent Methods 吧！今天一樣會搭配昨天的圖使用：

什麼是 Idempotent Methods？

先來看一下 RFC 9110 中對於 Idempotent Methods 的定義：

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.

當這個請求方法發出單一次請求與發出多次相同請求時，造成對於伺服器資源狀態的影響效果是一樣的時候，這個請求方法就會被定義是 Idempotent Methods（冪等性方法）。安全方法都是唯讀的，不管發出幾次請求都不會造成改變，因此安全方法也都會是冪等性方法分類中的一部分。

由於 PUT 是將目標資源進行整體的替換，就算是重複發出多次相同請求，最後的結果都會是一樣的。而 DELETE 重複刪除同樣文章時，差異只是在第一次成功刪除時，伺服器可能回傳的 status code 會是 200 OK，而多次重複刪除時，伺服器可能會回傳 404 Not Found，雖然回傳的狀態碼會有所不同，不過冪等性指的是對於伺服器上資源狀態的影響，因此 DELETE 也被視為是冪等性方法。

PATCH 雖然跟 PUT 類似，但 PUT 請求是將伺服器上原來的資源全部由新發送的版本取代，PATCH 請求則是透過一組指令去告訴伺服器如何將現有的資源修改成新的版本，而有的 PATCH 請求可能是累加的，例如以下請求：

{"op": "add", "path": "/-", "value": "foo"}

原本是一個空的陣列

[]

執行一次 PATCH 後結果如下：

["foo"]

執行兩次 PATCH 後結果如下：

["foo","foo"]

因為 PATCH 是基於現在的資料作出修改，所以在發出多次請求後最終的資料狀態會有所不同。

如果對於冪等性可能還沒有到很理解，這部影片或是這篇討論文章可能會有所幫助～

為什麼要定義出 Idempotent Methods？

在 HTTP 請求中，當網絡連接中斷或伺服器無法回應時，使用者代理（瀏覽器）或使用者端可能會自動重複發送請求，可以試想一下以下情景：

小明今天在蝦皮賣場訂購了一台iphone 16的手機，在他下訂單的時候，蝦皮賣場伺服器出現了bug，沒有顯示成功下單，於是小明就急匆匆地又下訂了一台，可是實際上第一筆訂單有存進資料庫中，只是沒有成功回傳下單成功，結果最後在伺服器中就會紀錄小明買了兩台手機....

雖然很像是詐騙集團很常說的重複下單🤣🤣🤣，不過如果沒有根據請求方法區別出是否符合冪等性，並加以限制使用者代理的自動重試，或是在客戶端做出非冪等性操作時，跳出如下的提醒視窗時，就會很容易導致預期之外的錯誤發生唷！

小結

今天介紹了請求方法中的冪等性方法分類如何定義，以及為什麼要做出這個分類，透過昨天跟今天的文章，我也更知道依據 HTTP 請求方法的規範的重要性，為了避免意料之外的狀況出現，也為了保障雙方的權益，這些分類可是不可或缺的～

參考資料

RFC 5789
RFC 9110
MDN
What is idempotency in HTTP methods?
Why PATCH is neither safe nor idempotent?
What is an idempotent operation?